Conventional techniques for controlling access to internal resources of enterprise networks from external servers and other devices may involve, for example, the use of secure sockets layer (SSL) virtual private network (VPN) gateways or other types of secure gateways.
A typical conventional SSL VPN gateway is configured to provide browser-based access to the internal resources of an enterprise network. Such internal resources may comprise servers, computers or other processing devices, from many different vendors, and running a wide variety of different protocols. Inbound transactions directed to the gateway are generally initiated using standard protocols such as hypertext transfer protocol (HTTP) or HTTP secure sockets (HTTPS). In a typical configuration, an SSL VPN gateway may not itself be a firewall, but may instead be located within the enterprise behind the firewall.
Examples of conventional SSL VPN gateways include the SA 700, SA 2000, SA 4000, SA 6000 and SA 6000 SP products commercially available from Juniper Networks, Inc. of Sunnyvale, Calif., USA, the EX-2500, EX-1500 and EX-750 products commercially available from Aventail Corp. of Seattle, Wash., USA, and the Permeo Base5 product commercially available from Permeo Technologies, Inc. of Austin, Tex., USA.
A significant drawback associated with conventional VPN gateways of the type listed above is that it can be difficult to handle alarms generated by internal resources of the enterprise. Such resources often comprise products from multiple vendors. Each vendor may have an external service provider that provides customer support for the products of that vendor. A given service provider may comprise, for example, technicians and expert systems that can process the alarms to resolve whatever problems may exist in the corresponding vendor products. Exemplary expert systems that may be used to process alarms are described in U.S. Pat. No. 7,302,611 B2, B2, filed Sep. 13, 2004 in the name of inventors S. Ganesh et al. and entitled “Distributed Expert System for Automated Problem Resolution in a Communication System,” which is commonly assigned herewith and incorporated by reference herein.
Generally, the conventional SSL VPN gateways are not configured to deliver alarms from multi-vendor products that are part of an enterprise network behind the firewall to their associated external service providers outside of the firewall, or to allow the service providers access to the products that generated the alarms. In many cases, a customer may have to call the service provider in order to let them know of a problem that has resulted in an alarm. The customer would then have to provide explicit authorization to allow a technician or expert system of the service provider to gain access to the product in order to resolve the problem.
Also, conventional SSL VPN gateways are typically designed to authenticate single users. It is impractical to authenticate the hundreds or even thousands of technicians that may be associated with the service providers that support the various multi-vendor products in a given enterprise. Service provider technicians may have to use hardware tokens or other similar mechanisms to obtain access to an enterprise network, and each service provider technician would have to use different sets of hardware tokens for each customer, which is impractical and expensive. Moreover, authenticating large pools of multi-vendor service provider technicians can place an excessive burden on the administration, authorization and authentication (AAA) server of a given enterprise, which is clearly undesirable.
The above-cited U.S. Pat. No. 7,590,761 B2 discloses an improved SSL VPN gateway or other type of secure gateway which can provide more efficient handling of alarms from multi-vendor products that are part of the internal resources of an enterprise network.
In an illustrative embodiment, an SSL VPN gateway comprises an alarm manager and provides support for inbound federated identity. The alarm manager receives an alarm from a vendor product that is part of a set of internal resources of the enterprise network, and routes the alarm to an external service provider for processing. The gateway receives from the service provider, responsive to the alarm, a federated identity which encompasses a plurality oftechnicians, expert systems or other servicing elements of the service provider. The gateway may grant one or more particular servicing elements of the service provider access to the alarm-generating vendor product based on the federated identity.
Despite the considerable advantages provided by the secure gateways disclosed in the above-cited patent application, a need remains for further improvements, particularly with regard to controlling access responsive to alarms generated by products that are part of the internal resources of an enterprise network. For example, conventional arrangements for providing such access outside of the secure gateway context may involve utilizing a network management system to reprogram a router responsive to a received alarm. However, such arrangements are unduly complex, and thus very expensive to implement in practical enterprise networks.